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REMARKS 

Favorable consideration of this application in view of the above amendments and the 
following remarks is respectfully requested. The specification has been amended to correct 
typographical and grammatical errors. Claims 1-13 have been amended to more clearly present 
the claimed subject matter. Claims 14-3 1 have been added to more fully recite the claimed 
subject matter. Applicant submits that no new matter has been added. Formal notice of such is 
respectfully requested. Claims 1-31 are pending. 

Attached is a marked-up version of the changes being made by the current amendment. 

Applicant asks that all claims be examined. Enclosed is a $198.00 check for excess claim 
fees. Please apply any other charges or credits to Deposit Account No. 06-1050, Ref. No. 
06975-062001 
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Version with markings to show changes made 

In the specification: 

Specification beginning at page 1, line 1 has been amended as follows: 

RELATED APPLICATIONS 

This application is related to U.S. Provisional Application No. 60/160,874, filed October 
22, 1999 A and entitled "Sharing A User's Personal Information," which application is 
incorporated by reference in its entirety. 

BACKGROUND 

The computer system 100 illustrated in Fig. 1 represents a typical hardware setup for 
executing software that allows users to perform tasks such as communicating with other 
computer users, accessing various computer resources, and viewing, creating, or otherwise 
manipulating electronic content - that is, any combination of text, images, movies, music or 
other sound, animations, 3D virtual worlds, and links to other objects. _The system includes, 
various input/output (I/O) devices (mouse 103, keyboard 105, display 107) and a general purpose 
computer 100 having a central processor unit (CPU) 121, an I/O unit 117, and a memory 109 that 
stores data and various programs such as an operating system 111, and one or ore application 
programs 113. The computer system 100 also typically includes some sort of communications 
card or device 123 (e.g., a modem or network adapter) for exchanging data with a network 127 
via a communications link 125 (e.g., a telephone line). 

As shown in Fig. 2, a user of a computer system can access electronic content or other 
resources either stored locally at the user's own client system 202 (for example, a personal or 
laptop computer) or remotely at one or more server systems 200. An example of a server system 
is a host computer that provides subscribers with online computer services such as email, e- 
commerce, chat rooms, Internet access, electronic newspapers^ and magazines[, etc]. Users of a 
host computer's online services typically communicate with one or more central server[s] 
systems 200 through client software executing on their respective client systems 202. 
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In practice, a server system 200 typically is [will] not [be] a single monolithic entity^ but 
[rather will be] is a network of interconnected server computers, possibly physically dispersed 
from each other, each dedicated to its own set of duties and/or to a particular geographic region. 
In such a case, the individual servers are connected by a network of communication links[,] in 
known fashion. 

A "browser" is an example of client software that enables users to access and view 
electronic content stored either locally or remotely, such as in a network environment (local area 
network (LAN), intranet, and wide area network (WAN) such as the Internet). A browser is 
typically used for displaying documents described in Hypertext Markup Language (HTML) and 
stored on servers connected to a network, e.g., the Internet. Technically, a web browser is a 
client program that uses the Hypertext Transfer Protocol (HTTP) to make requests of web 
servers throughout the Internet on behalf of the browser user. A web server contains, in addition 
to the HTML and other files it can serve, an HTTP server daemon, which is a program designed 
to wait for HTTP requests and handle those requests when received. 

Fig. 3 is a screenshot of a browser application 300 (Netscape Navigator) displaying a 
typical HTML document, or web page 302. As shown therein, a single web page 302 may be 
composed of several different files potentially of different data types 304 (for example, text , 
graphics, images, virtual worlds, sounds, or movies[, etc]). In addition, a web page can include 
links 306 pointing to other resources (for example, web pages or individual files) available on the 
network. Links 306 can take virtually any visual form, for example, the[y] links can appear 
either as a text string or as a graphical image or a combination thereof. Each link 306 has an 
associated URL pointing to a location on the network. When a user "clicks on" or otherwise 
selects a displayed link 306, the browser can automatically [will] retrieve a web page or other 
resource corresponding to the link's associated URL and display it to, or execute it for, the user. 

A user can instructs] a browser to access a[n] HTML document!,] °r web page[,] by 
specifying a network address [,] or Uniform Resource Locator (URL)[,] at which a desired 
document resides. URLs are defined in Internet standard RFC 1738 to include an indication of 
the protocol to be used and the location of a resource on a web server. In response to instructions 
from the user , the browser contacts the corresponding server hosting the requested webpage, 
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retrieves the one or more files that make up the webpage, and then displays the webpage in a 
window on the user's computer screen. 

Web pages can typically [are]be transported using [the HyperText Transfer Protocol 
GHTTP[)] as defined in Internet standard RFC 2068. HTTP is a set of rules for exchanging files 
5 (text, graphic images, sound, video, and other multimedia files) on the World Wide Web 
(WWW) . Relative to the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of 
protocols [(] which are the basis for information exchange on the Internet!)], HTTP is an 
application layer protocol. 

When a user of a web browser sends a[n] HTTP request by typing in an URL or clicking 
10 on a hypertext link, the browser builds a[n] HTTP request and sends it to the address indicated 
by the URL. The HTTP server daemon in the destination server machine receives the request 
and, after any necessary processing, the requested file is returned. The response is sent [backjto 
the browser where it can be displayed to the user. The HTTP protocol response includes various 
codes detailing the result of the request. For example, return code 404 indicates that the 
15 information requested was not found. For transactions requiring security, the HTTP connection 
can be secured with encryption. This variant is known as Secure HTTP (HTTPS) or Secure 
Socket Layer (SSL). 

HTTPS [Secure Hypertext Transfer Protocol] is web protocol developed by Netscape 
Communications . Inc. (Netscape) of Mountain View, California and is implemented in several 

20 browsers. The HTTPS protocol encrypts and decrypts user page requests as well as the pages 
that are returned by the web server. HTTPS uses Netscape's [Secure Socket Layer (] SSL[)] as 
a sublayer under its regular HTTP application layer. HTTPS uses port 443 instead of HTTP port 
80 in its interactions with the lower layer, TCP/IP. SSL uses a key size of a predetermined - 
number of bits (typically between 40 and 128) for the RC4 stream encryption algorithm, which is 

25 considered a minimal degree of encryption for commercial exchange. 

When visiting an electronic commerce merchant, a user typically is presented with a web 
page order form URL that starts with " https:// ", indicating the use of the HTTPS protocol. When 
sending the response, the browser will use the HTTPS layer for encryption. The 
acknowledgement received from the server also will travel in encrypted form using HTTPS, and 

30 will be decrypted by the browser's HTTPS layer. 
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HTTPS and SSL support the use of X.509 digital certificates form the server so that, if 
necessary, a user can authenticate (i.e., confirm the identity of) the sender. SSL is an open, 
nonproprietary protocol that Netscape has proposed as a standard to the World Wide Web 
Consortium (W3C). HTTPS is not to be confused with SHTTP, a security-enhanced version of 
5 HTTP developed and proposed as a standard by EIT. 

A digital certificate is an electronic token that establishes the credentials of a party doing 
business or other transactions on the web. Certificates farel can be issued by a certification 
authority (CA). Typically, certificates can contain a party's names, a serial number, expiration 
dates, a copy of the certificate holder's public key (used for encrypting and decrypting messages 
10 and digital signatures), and the digital signature of the certificate-issuing authority so that a 
recipient can verify that the certificate is real. Some digital certificates conform to a standard, 
X.509. Digital certificates can be kept in registries so authenticated users can look up other 
user's public keys. 



15 maintaining] client side persistent data. A cookie is a token, for example, a special text file, that 
a web site stores on a user's hard disk so that the web site stores on a user's hard disk so that the 
web site can remember something about [a]the user at a later time. Typically, a cookie records a 
user's preferences when using a particular site. Under HTTP, each request for a web page is 
independent of all previous requests. For this reason, a web page server has no memory of what 

20 pages it has sent to a user previously or anything about that user's previous visits. The cookie 
mechanism can allow[s] the server to store its own file on the user's own computer. The file 
[isjcanbe typically stored in a subdirectory of the directory used to install the browser software. 
The cookie subdirectory [will]can contain cookie files for each web site visited by the user that 
uses cookies. Cookies are commonly used to keep track of which banner ads a user already has 

25 encountered. This tracking can assist [allows] web sites [to]in rotat[e]ing the banner ads 

presented fsent] and thereby minimize repetition [as]to the user based on a user's browser type or 
other information provided to the web site. In order for cookies to be used for tracking, [Wlw eb 
users, must agree to let cookies be saved on their computers by configuring their browsers to 
accept cookies. 



HTTP also includes a mechanism referred to as a "cookie," which is used [forjto 
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Consumers can buy and sell products and services shown on web pages via electronic 
commerce ("e-commerce") transactions. To enable these transactions, a consumer and merchant 
[must] exchange personal and financial information concerning the online transaction, such as 
their credit card, billing address* and shipping address. Conventional payment systems 
5 associated with many Internet commerce sites therefore require customers to type their credit 
card and mailing information into a[n] HTML form. 

Figs. 4A and 4B show an example of an e-commerce form 400. the information form the 
form 400 typically includes name 405, shipping address 410, billing address 415, and credit card 
number 420. This information is submitted to the merchant, who then uses the information .to 

10 complete the transaction using various known fulfillment and delivery mechanisms. 

Navigating and completing [these] such forms involves a great deal of repetition and 
associated convenience to users when providing name, shipping address, billing address, and 
credit card data to merchants. Completing electronic forms often is a tedious and error-prone 
process. Furthermore, using these payment systems, customers visiting several online stores 

15 [must] re-enter their payment/address information at each online store [where] at which they 
make a purchaseJJ For many stores* [even requiring] shoppers [to] re-enter [their] payment 
information [on] at each subsequent visit. 

To facilitate the process of [filling out] completing forms, "form fillers" have been 
developed. These applications can automate the filling of forms encountered when visiting web 

20 sites. The form filler can recognize[s] forms in the HTML and can record[s] the data entered in 
the fields when the user fills out the form for the first time. Then, when similar fields show up in 
subsequent forms, the form filler can use the recorded data to automatically fill out these fields. 
An example of such a form filler is built into Microsoft Internet Explorer 5.0. Figs. 5 A, 5B, and 
5C show a form filler application built into a browser automatically filling out the fields in an e- 

25 commerce form. Some form fillers [further] can allow the user to maintain several "identities" 
to help protect privacy. Each identity keeps track of a separate set of form data that will be used 
to fill in new forms. 

A similar^ but more sophisticated^ approach to facilitating online transactions is the 
digital wallet. A digital wallet is a software application that allows the user to input shipping and 
30 billing data once and reuse this information at many different web sites to complete a purchase. 
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Digital wallets that ffilll complete merchant forms or directly transfer data to merchants have 
been successfully built into browsers in several ways, including as helper applications to 
browsers, stand-alone applications, and browser plug-ins. 

Once the digital wallet is set up, the user can store, manipulate, and pay for Internet 
5 purchases with various types of payment instruments^ [(]e.g., credit cards or electronic cash[)]. 

Client-based personal electronic wallets have been developed to relieve this burden. 
Client-based wallets store e-commerce information for a particular user at the machine operated 
by that user. When that machine interfaces a merchant website through the I[i]nternet, e- 
commerce information stored in the local wallet may be transferred to the merchant. However, 
10 because client-based wallets reside on the user machine, these wallets are subject to the 

limitations of the machine upon which they reside. For instance, security attacks on the user 
machine may be used to target the wallets residing thereon. In addition, limitations on 
portability for the machine result in limitations for the wallet. 

SUMMARY 

1 5 One or more of the following advantages may be provided. The techniques and methods 

described here may enable the user to drastically reduce the amount of work required to fill out 
forms on web pages. This may be accomplished in one or more of the following ways. First, 
multiple pages of content [can be filled out] may be completed without requiring the user to 
view each page. Presenting only those fields and forms that are not automatically completed 

20 minimizes the work for users. Users can be selectively queried for any merchant-specific missing 
fields, thus optimizing the form filling process. Users need not inspect each form and approve its 
contents. Further, merchants using the techniques and methods described here may be able to 
provide information that is tailored and customized for the user, thus increasing the usefulness of 
the merchant's content to the user. 

25 Other advantages for the user include ease of use [in that] since no additional software is 

required. Father, as the user is not tied to a single computer, the [other benefits described here 
can be realized] user's information can be accessed from any computer capable of accessing the 
merchant's site, regardless of [its] location. In addition, the security of the user^s [gains some 
security, as the invention reduces the] improves because risks associated with data sniffing on 
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the user's local area network and accessing storage devices attached to the user's computer can 
be reduced . 

[For t]The merchant [, the techniques and methods presented enable merchant to] 

can access specific information about a customer's preferences and history [. The merchant 
can] and use that information to customize the content presented. Merchants can track 
completed purchases in order to better handle service and information requests. Because [the] 
merchants can access the information using a [well-defined] protocol, merchants can easily 
modify forms without causing problems with many different types of software. Merchants can 
obtain demographic data for future targeted advertising. An intimate relationship between the 
merchant, the user, and the online service [is] can be fostered. 

These techniques and methods can be generalized and applied to [any type of] a variety 
of user preference data, [Qe.g., travel preferences [)], in addition to shipping, billing, and 
demographic data. [In addition, they may be implemented using] Implementation can as a 
system, method, software, or some combination thereof 

Details of one or more implementations are set forth in the accompanying drawings and 
the description below. Other features and advantages will be apparent from the description and 
drawings, and from the claims. 



DESCRIPTION OF DRAWINGS 

Fig. 1 shows a block diagram of a computer system. 
20 Fig. 2 shows a typical network-computing environment. 

Fig. 3 shows a browser application displaying [a typical] an exemplary web page. 

Fig. 4A shows a browser displaying an exemplary e-commerce form. 

Fig. 4B shows the second page of the e-commerce form of Fig. 4A. 

Fig. 5 A shows exemplary results of using a form filler application. 
25 Fig. 5B shows the second page of exemplary results of Fig. 5 A. 

Fig. 5C shows the third page of exemplary results of Fig. 5 A. 

Fig. 6 is a host-to-host architecture for sharing e-commerce transaction information. 

Fig. 7A shows an authentication process. 

Fig. 7B shows the process for requesting purchase information. 
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Fig. 7C shows the process for requesting credit card numbers. 
Fig. 8 is a flowchart of the typical sequence of screens displayed to users. 
Fig. 9 is a screenshot of an exemplary merchant's product ordering page. 
Fig. 10 is a screenshot of [the] an exemplary framework authentication page. 
Fig. 1 1 A is a screenshot of [the] an exemplary framework registration page. 
Fig. 1 IB is the second page of the screenshot of Fig. 12 A. 

Fig. 12 is a screenshot of [the] an exemplary merchant's order confirmation page. 
Fig. 13 is a screenshot of [the] an exemplary framework edit preferences page. 
Fig. 14 is a screenshot of [the] an exemplary framework edit credit cards page. 
Fig. 15 is a screenshot of [the] an exemplary framework edit addresses page. 
Fig. 16 is a screenshot of [the] an exemplary framework change security page. 
Fig. 17 is a screenshot of [the] an exemplary framework delete preferences page. 
Fig. 18 is a screenshot of [the] an exemplary framework customer service page. 
Fig. 19 is a screenshot of [the] an exemplary merchant's choose addresses page. 
Fig. 20 is a screenshot of [the] an exemplary merchant's order information page. 
Like reference symbols in the various drawings may indicate like elements. 

DETAILED DESCRIPTION 

Quick checkout (QC) is a host-based system for sharing personal information of a 
network user with the resources accessed by that network user. QC generally involves either or 
both of two data stores, referred to as passport and wallet. Passport and wallet [are] can be host- 
based collections of routinely requested personal billing, shipping* and demographics 
information (hereinafter^ "personal information"). [They may] Passport and wallet can be 
maintained independently or collectively. A user with a populated passport or wallet [may] can 
choose to pass selected information to web sites, automatically or with very little effort, to enable 
an enhanced browsing experience or to assist in the completion of an online transaction. 

For instance, when merchants offer QC as a payment option and the [consumer] user 
elects to invoke QC, the merchant [simply] passes the order information to a pre-determined 
SSL-enabled QC form that is [then] displayed to the consumer. Payment information and 
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shipping address [are] can be sent from the QC database to the QC form, and the form is 
confirmed, rejected or modified by the [consumer] user . In this manner, the [consumer] user 
does not need [not] to redundantly enter payment information for each transaction or each . 
merchant. Rather, the[y] user can [may] rely on the wallet for this information!, merely] 
5 confirming [its] the accuracy of the information . As will be explained in greater detail below, 
when the wallet includes several options for payment, shipping, etc., the consumer [may] can 
establish default information, and has the ability to select desired information from among that 
stored. 

This host-based system facilitates [seemless] an integration with other merchant services 

10 as well as the surrounding wallet/passport provider environment. Because the wallet and 
passport are host-based, the[y] wallet and passport can be [are inherently] portable, 
[updateable] update able , secure^ and simple to setup and use. 

QC can be used to share many different pieces of a user's personal information, before 
and during an e-commerce transaction. For instance, using QC, selected user information [may] 

15 can be shared with a merchant server[s] upon a user's access to [their] a web site[s] or later^ 
when performing an e-commerce transaction. More specifically, upon access to a merchant's 
web site, [it is possible to share personal information to enable] the merchant [to] can 
personalize the content and services provided to the user. [In this sense, ]QC can share 
[virtually any other type] a variety of personal information, such as travel preferences, 

20 demographic information, food choices, and medical information. Thereafter, upon checkout, [it 
is possible to share] personal information of a more specific nature, generally concerning e- 
commerce informatio n, can be shared . For instance, commercial information such as user name, 
address, and credit card information can be shared^ when appropriate^ to further e-commerce 
transactions. Each user's information [is] can be stored in a "profile" that can be updated 

25 [frequently]. This information can be stored in a[ny] proprietary or commercially available 
relational or object database management system (DBMS), such as provided by Oracle, Inc. or 
Informix, Inc. 

Fig. 6 [shows one potential] illustrates an exemplary architecture of the framework, 
known as a "host-to-host" architecture. [This architecture leaves t]The client computer 601 of 
30 this architecture is not [unmodified. The client computer 601, network host 602, and the 
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preferences server 603 can communicate with each other to exchange user preferences 
information efficiently with [a minimum of] minimal user interaction. Once the preferences 
server 603 authenticates the user, the network host 602 can [directly] communicate with the 
preferences server 603. 

5 HTTPS is generally used as a transport for requests and responses.!;] [h]However, other 

protocols[also] could be used as transport mechanisms. Input parameters in requests and return 
values [must] can be URL-encoded [to ensure] so that nonstandard characters [are] can be 
properly transmitted over the Internet. Furthermore, return codes from the requests [may] can be 
used to verify their success. 

10 Although the framework does not require a fixed sequence of requests from network 

hosts, communications between the user, the merchant, and the framework typically follow a 
particular pattern, illustrated in Figs. 7 and 7A, 7B, and 7C. [The basic pattern is to] Generally, 
the process includes [authenticate] authenticating the user, request ing purchase information, 
requesting payment information, and [finally] then [to place] placing the order. Each [of these] 

15 step[s] is described further below with respect to Figs. 7A-7C, which show[s] client computer 
701, merchant web server 702, preferences server 703, preferences database 704^ and network 
705. 

Fig. 7A shows the exchange of messages between the user, merchant, and the framework 
server during [the] authentication [step]. First, in step 710a, the merchant server 702 provides a 

20 browser at client computer 701 access to its web page. The user [is able to] can view the web 
page and can select a set of products or services offered by the merchant, and thereafter [may] 
can invoke "QuickCheckout" to proceed with an e-commerce purchase. When QuickCheckout 
is invoked, an authentication request is sent 710b [sent710b] to the preferences server 703 for 
authentication of the user . After the user enters an authorized username and password, a session 

25 identifier is generated 710c and returned by the preferences server 703. [, and] [t]The user's 

browser 701 is [again] directed to a web page on the merchant server 702. The session identifier 
[thenis] is then sent 710d to the merchant, e.g., in the form of a cookie. For authentication 
throughout the remainder of the session, this session identifier [will] can be sent with 
[eachsubsequent] each subsequent communication by the merchant server 702 to the 

3 0 preferences server 703 . 
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Fig. 7B shows the exchange of messages that occurs while getting purchase information 
to the merchant server 702. In step 720a, immediately after receiving an authentication 
confirmation 710d, the merchant server 702 sends the session identifier to the preferences server 
[703with] 703 with a request for information about the user. The merchant server 702 also sends 
5 an X.509 SSL server certificate and a set of merchant preferences in the authentication request of 
step 720a. This certificate is used by the preferences server 703 to verify the identity of the 
merchant server 702 initiating the request for information. The preferences requested by the 
merchant server 702 of the preferences server 703 [will] can be used to tailor later content and 
services provided by the merchant server 702 to the client computer 701 . 

10 In step 720b, preferences information about the user [are] can be returned by the 

preferences server 703 to the merchant server 702. In step 720c, the information [is] can be 
formatted into a web page requesting confirmation of the information from the user at client 
computer 701. At this stage, only a portion of any previously entered credit card information is 
returned for security purposes, the returned information providing enough information for the 

15 user to confirm and/or edit the user information at this stage. 

Referring to Fig. 7C, the process of obtaining payment information is described. At step 
730a, once the preferences information is confirmed by the user, the merchant server 702 sends 
the session identifier with a request for full payment information to the preferences server 702. 
The user's full credit card information can then[is] be returned to the merchant server 702 in step 

20 730b. If the merchant server 702 does not receive the information, [it] the merchant server 702 
can check the HTTP return status code and take appropriate action. Otherwise, once payment 
information is received by the merchant server 702, the transaction [may] can be processed with 
the credit card company in step 730c, and wait for authorization. The preferences server 703 can 
also [may] process the payment information with the credit card company. 

25 Finally, the results of this transaction are sent to preferences server 703 for customer 

service, record keeping, and order tracking purposes. These results [are] can be stored in the 
database for use in future transactions. The merchant can check the HTTP return status code 
from the preferences server 703 and take appropriate action^ if a failure occurs. 
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The flowchart of Fig. 8 shows primary paths involved in a typical transaction. The 
process also includes appropriate error handling and alternative entry points when necessary. 
[The] An exemplary sequence of screens from the user's perspective is shown in Figs. 9-20. 

[The first step 801 in the process of Fig. 8 is for] Referring to Fig. 8, the user [to] can 
5 browse the merchant's site and can select some items for purchase (step 801) . Fig. 9 shows such 
a screen with some products 901 selected for purchase. From this page, the user clicks the "AOL 
Quick Checkout" button 902. This button initiates the authentication request described above. 

[The n]Next A [step 802 in the process of Fig. 8 is to show] the user can be shown the 
authentication page from website, e.g., the AOL site (step 802) . This page is shown in Fig. 10. 

10 If the user has an AOL account (803a), the[y] user enters [their] his screen name 1001 and 
password 1002, and then clicks on the "OK" button 1003. If the user does not have an AOL 
account (803a), [then] the user can [register(803)] register (803) by clicking on the "Signup 
Now!" button 1004. An exemplary form for [T]the registration step 803 [in the process of Fig. 
8 involves filling out a form,] is shown in Figs. 1 1 A and 1 IB. The form can request [contains] 

15 credit card information 1101, shipping information 1 102, and account information 1 103. After 
entering [the required] this information, the user can register by clicking the "OK" button 1 104. 

Once the user has either successfully authenticated or registered, the [next step 804a in 
the process of Fig. 8 is to show the] user is shown a web page [allowing their] to review [of] 
the order information. Fig. 12 shows how this page details the order 1201 and shows the default 

20 transaction information 1202 provided by the framework server to the merchant. Only the last 
four digits of any credit card number 1203 are provided at this stage. From this screen, if the 
shipping addresses are inaccurate (804b), the user can choose shipping addresses by clicking on 
the "Choose Shipping Addresses" buttonl204. Also, if the preferences are inaccurate (804b), the 
user can choose to edit the transaction information by clicking on the "Edit Information" button 

25 1205. When the user is satisfied with the addresses and transaction information, the[y] user can 
click on the "Complete AOL Quick Checkout" button 1206 to confirm the transaction. By 
confirming the transaction, the user is authorizing the merchant to complete the transaction with 
the credit card company using the information displayed. 



30 Fig. 8 is to show] the user is shown a set of edit screens (step 805) . The first such screen is 



If the user chooses to edit transaction information, [the next step 805 in the process of 
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shown in Fig. 13 and [allows] the user can, for instance, [to] edit credit cards 1301, edit shipping 
addresses 1302, change security information 1303, delete AOL Quick Checkout settings 1304, 
and request customer service 1305. Once the user makes a selection, the appropriate screen is 
displayed. 

5 If [in step 805] the user chooses to edit credit cards, [the next step 806 in the process of 

Fig. 8 is to display the] a screen^ as shown in Fig. 14 (step 806), is displayed tof . This screen] 
allow[s] the user[s] to select a credit card for use in the current transaction by selecting [one of 
their] a currently defined credit card[s] 1401 and clicking the "Use This Card" button 1402. The 
[U]user[s] also can edit a credit card's information by clicking the "Edit This Card" button 1403. 

10 To edit a card or add information about a new credit card, the user can [fill in] complete the 

fields in the lower portion of the screen 1404. When the user is finished editing, the[y] user can 
click the "Add This Card" button 1405 to add the information to [their] his profile. 

If [in step 805] the user chooses to edit addresses, the process is [very] similar to that for 
editing credit cardsj. The next step807 in the process of Fig. 8 is to display the screen] as 

15 shown in Fig. 15 (step 807) . This screen allows a user[s] to select a shipping address for use in 
the current transaction by selecting one of the currently [definedshipping] defined shipping 
addresses 1501 and clicking the "Use This Address" button 1502. The [U]users can also edit an 
address by clicking the "Edit This Address" button 1503. To edit an address or add a new - 
address, the user can [fill in] complete the fields in the lower portion of the screen 1504. When 

20 the user is done editing, the[y] user can click the "Add This Address" button 1505 to add the 
information to [the] Ins profile. 

If [in step 805 of Fig. 8] the user chooses to change security information, [the next step 
808 in the process of Fig. 8 is to display] the screen, as shown in Fig. 16[. This screen] is 
displayed (step 808) to allow[s] a user to enter 1601 and confirm 1602 a new password by typing 

25 [it] the new password into a form. [A] The user can also change the email address 1603 

associated with his profile. When the user is done editing, the[y] user can click the "OK" button 
to confirm the changes and continue. 

If [in step 805 of Fig. 8] the user chooses to delete AOL Quick Checkout settings, [the 
next step 809 in the process of Fig. 8 is to display] the screen shown in Fig. 17 is displayed 

30 (step 809), [ . This screen] to ask[s] a user to confirm that the[y] user wants to delete all of [his] 
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credit card and shipping address information stored in the profile. [A] The user can confirm 
[this desire] by clicking on the "Yes" button 1701. 

If [in step 805 of Fig. 8] the user requests customer service, [the next step 810 in the 
process of Fig. 8 is to display] the screen shown in Fig. 18 is displayed (step 810) with f. This 
5 screen displays] customer service information 1801 for [all] the companies associated with the 
AOL Quick Checkout service [. This screen also offers] and additional information about the 
AOL Quick Checkout service 1802. 

If the user in step 804 of Fig. 8 decides to choose addresses instead of editing 
preferences, [the next step 811 in the process of Fig. 8 is to display] the screen shown in Fig. 

10 19 is displayed to [. This screen] show[s] the products 1901 selected by the user for purchase 
(step 811) . The user can assign one of the addresses 1903 to each product by selecting the 
appropriate number in the pulldown menu 1902. Once the user has finished selecting addresses, 
the[y] user can finalize his choices by clicking on the "Use These Addresses" button 1904. In 
addition, the user can edit addresses, as discussed above in step 807 of Fig. 8, by clicking the 

1 5 "Edit Addresses" button 1 905 . 

If the user in step 804 of Fig. 8 is satisfied with the transaction selections, and has clicked 
the button 1206 to complete the transaction, [the next step 812 in the process of Fig. 8 is to 
display] a final page verifying that the transaction has been completed is displayed (step 812) . 
This screen, as shown in Fig. 20, displays the transaction information 2001 that was used by the 

20 merchant to complete the credit card purchase. The display [may] can include a confirmation 
string 2002 or order identification string 2003 for record keeping purposes. 

Fig. 21 shows an implementation as part of one particular infrastructure ofl. The figure 
shows] the host-to-host architecture, as described above, with the addition of a proxy 2102. The 
[proxy2102] proxy 2102 can act[s] as an intermediary for [all] traffic between [the] host service 

25 computers and the Internet. The [proxy2102] proxy 2102 can perform[s] load balancing by 
switching connections to the least utilized hardware for [to ensure that a high degree of] 
performance [is maintained]. The [proxy2102] proxy 2102 also contains a list of hosts that can 
be redirected to internal AOL sites. The internal sites provide AOL users with a more consistent 
look and feel. The internal sites can also be more tightly integrated with the AOL system 

30 because they are under AOL control. 
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In another implementation, as a user[s] selects [all of the] items [they wish] to purchase 
from a particular merchant, the merchant collects and stores information about the purchase 
order, designated with an order identifier that is used to unify the order information. The order 
information [typicallyis] typically is presented to the consumer (user) in a shopping cart upon 
5 request or at checkout. Using this order information, the consumer can confirm the contents of 
the[ir] shopping cart by invocation of QC or otherwise, as the order identifier can tie[s] a [any] 
subsequent QC information to the order information stored by the merchant. 

Then, when the consumer launches QC , for example, by clicking on [using] an icon at 
the merchant website, the merchant authenticates the consumer as a QC user. To do so, the 

10 merchant directs users to the AQC aolqc_auth url for authentication. If the GET to this url 
returns successfully, the [merchant can be assured that the] user can be [has been 
appropriately identified and] "logged in" as an AQC member. For example, the GET returns 
with a session identifier (aolqc_session_id) which serves as a key to the consumer account. 
Thereafter, the session id is passed with [virtually every] each backend call made by the 

15 merchant [thereafter Qe.g., to retrieve billing information for the customer[J or to enable 
editing by the customer [)]. [After] Once the consumer is authenticated once by a merchant, 
the[y] consumer will not be redirected back to the authentication page until the[y] consumer 
[have] has logged off of the AOL service. 

If authenticated, payment and shipping information is collected from QC. Preferably, the 

20 merchant makes a host-to-host call to fetch a "pretty print" user-displayable version of the user's 
default billing and shipping information from the QC, which [version] does not include all of the 
information. The merchant then automatically produces a form that includes an order id , which 
[and that] is posted to https://payment.aol.com/placeorder. For instance, a standard form 
[might] can include the parameters listed in Appendix A (see parameters spanning pp 5-6 of 

25 AOL QC Merchant Connectivity Specification filed with provisional application number 

60/160,874 filed October 22, 1999, which is incorporated by reference in its entirety). Using the 
order_allow_multi_shipto field of the placeholder form, [it is possible for] a merchant [to] can 
enable designation of different shipping destinations for different aspects of the order^ [Ge.g., per 
unit or per item[)]. Similarly, other fields [may] can be duplicated to provide flexibility, as 

30 needed. 
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In response to the placeorder form, available QC information [is] can be returned from 
the wallet and [is]posted at the merchant. Default QC information [may] can be automatically 
selected to eliminate the need for additional user interaction^ [(] unless editing is necessary [)]. 
Alternatively, the consumer [may] can [be required to] select among available QC information 
5 [(]e.g., credit card, shipping address information!)]. In either case, a subset of the sensitive QC 
information from the wallet [is] can be provided to the merchant in response to the placeorder 
request. This subset can include enough for consumer to confirm/select, but intentionally omits 
some information to avoid possible security problems , such as [(]trojan horses [, etc)]. The 
selected subset of QC info rmation [is] can be posted by QC host to the merchant site at the 

10 https://payment.aol.com/order_target_url page for future use in creating a confirmation page 
combining order and QC information. Fields from an exemplary form are listed on pgs. 6-7 of 
AOL QC Merchant Connectivity Specification, which was filed with provisional application 
number 60/160,874 filed October 22, 1999, which is incorporated by reference in its entirety). If 
the merchant can allow [s] multiple shipping destinations for aspects of a single order, and the 

15 consumer [has] can designate[d] multiple destinations in the information provided by the 
merchant to the host, multiple posts [may] can be made by the host to the 

https://payment.aol.com/order_target_url page[,]_ [e]Each post [having] can have the same order 
id A number but different information where appropriate to accomplish the consumer order. - 
After the consumer is redirected to the merchant site, the merchant can provide[s] an 

20 order confirmation page displaying the order and payment data. Specifically, the merchant can 
generate^] a form that displays the selected QC info and that queries the consumer to confirm 
the purchase. The confirmation page posts to a designated location known to wallet host, e.g., 
https://payment.aol.com/confirmorder. Fields from an exemplary form are listed in Appendix C 
(see list of parameters listed on p8 of AOL QC Merchant Connectivity Specification). If the 

25 merchant allows multiple shipping destinations for aspects of a single order, the consumer [has] 
can designate [d] multiple destinations in the information provided by the merchant to the host, 
and multiple posts [are] can be made by the host to the https://payment.aol.com/order_target_url 
page with the same order id number[,] . [t]The merchant [will] can generate a confirmation page 
for each part of the order. Generally, information is filtered before being return[ing]ed to the 

30 merchant for confirmation (to prevent merchant from obtaining enough financial info rmation to 
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complete transaction until after the complete transaction is confirmed by consumer). The 
merchant can then [displaysa] display a screen requesting confirmation of shopping cart to 
selected credit card [(]with limited information being shown about credit card[)]. 
After the order has been confirmed, three processes are performed: 
5 1 . the customer is redirected to the ht1p://payment.aolxom/order_return_url page A 

which displays a message from the merchant thanking the customer for their order, 

2. the merchant receives complete credit card information from the host along with 
other order information that is posted [toa] toa target url specified in the order_target_url field 
of the initial post generated by the merchant. This information is used by the merchant to deliver 

10 the ordered goods. An exemplary format for the order information is shown by appendix D (see 
[pp]pp 8-10 of AOL QC Merchant Connectivity Specification), and 

3. the merchant pushes order data to a URL accessible to the wallet host for 
customer service, record keepingi and order tracking purposes. 

Using this system and the ability to store and share personal information, [it is possible 

15 to provide] enhanced functionality such as parental controls, AOL rewards, gift reminders, 
purchase history, and keyword billing can be provided . 

Furthermore, integration with a service provider enabling several screen-names for a 
single account can allow[s] the user to designate separate wallets/passports for different members 
on an account, each drawing on some common and some independent information. For instance, 

20 several family members having different screen-names [may] can each maintain independent 
wallets with separate e-commerce information^ while being provided access to a shared wallet 
having shared e-commerce information. In this manner, selected credit cards or e-commerce 
information [may] can be made accessible to some or all screen-names without sharing all credit 
cards or other e-commerce information. Furthermore, when combined with the passport 

25 functionality, this model can allow[s] information to be maintained and communicated for each 
independent screen-name. 

The techniques, methods, and systems described here [may] can find applicability in any 
computing or processing environment in which electronic content [may] can be viewed, 
accessed, or otherwise manipulated. For instance, the concept of sharing e-commerce 

30 transaction information between hosts in a networked computing environment [could] can be 
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applied whenever those preferences are useful to a third party, such as an e-commerce merchant. 
One such environment can involve [s] a computer system^ [(]e.g., a Microsoft Windows-based PC 
or Apple MacintoshJ) that is] connected to the Internet. 

Various implementations of the systems and techniques described here [may] can be 
5 realized in digital electronic circuitry, or in computer hardware, firmware, software, or in 

combinations thereof. A system or other apparatus that uses one or more of the techniques and 
methods described here [may] can be implemented as a computer-readable storage medium, 
configured with a computer program, where the storage medium so configured causes a 
computer system to operate on input and/or generate output in a specific and predefined manner. 
10 Such a computer system [may] can include one or more programmable processors that receive 
data and instructions from, and transmit data and instructions to, a data storage system, and 
suitable input and output devices. 

Each computer program [may] can be implemented in a high-level procedural or object- 
oriented programming language, or in assembly or machine language if desired; and in any case, 
1 5 the language [may] can be a compiled or interpreted language. Suitable processors include" by 
way of example, both general and special purpose microprocessors. 

Generally, a processor [will] can receive instructions and data from a read-only memory 
and/or a random access memory. Storage devices suitable for tangibly embodying computer 
instructions and data can include [all] forms of non-volatile memory, including semiconductor 
20 memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as 
internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. 

Any of the foregoing [may] can be supplemented by, or implemented in, specially 
designed ASICs (application specific integrated circuits). 

A number of implementations have been described. Nevertheless, it will be understood 
25 that various modifications [may] can be made without departing from the spirit and scope of the 
invention. For example, advantageous results still could be achieved if steps of the disclosed 
techniques were performed in a different order and/or if components in the disclosed systems 
were combined in a different manner and/or replaced or supplemented by other components. 

Accordingly, other [embodiments] implementations are within the scope of the following 

30 claims. 
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In the claims: 

Claims 1-31 have been amended as follows: 

1 . A computer-implemented method for sharing a user's personal information with a 
host computer in a networked computing environment, the method comprising: 

gathering personal information from a user of [the] a computer network; 
storing the user's personal information at a first network server; 
receivings at the first network server^ a request for the user's personal information from 
another network server; and 

sending the requested information to the other network server. 

2. The method of claim 1, wherein gathering comprises requesting information 
directly from the user. 

3. The method of claim 1, wherein gathering comprises monitoring user activity. 

4. The method of claim 1, wherein gathering comprises soliciting information from 

others. 

5. The method of claim 1 , wherein the other network server corresponds to a 
business entity with whom the user is engaged in a transaction. 

6. The method of claim 1 , wherein personal information includes one or more of the 
user's name, address, credit card information, telephone number [s], facsimile number, e-mail 
address, employer name, employer address, work telephone number [s] 5 buying history, travel 
preferences, food preferences, medical information, and personal interests. 



7. The method of claim 1, wherein storing comprises saving the personal 
information in a database. 
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1 8. The method of claim 1 , wherein the other network server is controlled by an .e- 

2 commerce merchant. 

1 9. The method of claim 1 , wherein the other network server corresponds to a web 

2 site. 

1 10. The method of claim 1, further comprising authenticating the user prior to sending 

2 the requested information to the other network server. 

1 11. The method of claim 1 , further comprising authenticating a party associated with 

2 the other network server prior to sending the requested information to the other network server. 

1 12. The method of claim 10 [or 11 ] A wherein authenticating comprises verifying a 

2 username and password. 

1 13. The method of claim 10 [or 11 ] x wherein authenticating comprises checking a 

2 digital certificate. 



New claims 14-31 have been added. 



In the abstract: 

A host-based system for sharing personal information of a network user with the 
resources accessed by that network user. The host-based system generally involves either or 
both of two data stores, referred to as passport and wallet. Passport and wallet are host-based 
collections of routinely requested [personal billing, shipping and demographics information 
(hereinafter "]personal information [")• They may] and can be maintained independently or 
collectively. A user with a populated passport or wallet [may choose to] can pass selected 
information to web sites, automatically or with very little effort, to enable an enhanced browsing 
experience or to assist in the completion of an online transaction. 



